The present invention relates generally to multicasting and specifically to a method for selecting a resource from a plurality of multicasting resources for providing a desired service.
Multicasting allows one device on the Internet to send content to multiple other devices that have identified themselves as interested in receiving the originating device's content. One example of multicasting is a digital video distribution system for delivering digital video over Internet Protocol (IP) over Asynchronous Transfer Mode (ATM) over Digital Subscriber Line (DSL). Referring to FIG. 1, a digital video distribution system is represented generally by numeral 100. The distribution system 100 comprises a multicast capable broadband loop carrier (BLC) 102, a Plain Old Telephone System (POTS)/DSL loop 104, a DSL modem 106, and a plurality of set top boxes 108. The DSL modem 106 is coupled to each of the set top boxes via a local area network (LAN) 110. The distribution system 100 couples a media source 112 with a plurality of displays, or televisions 114. Generally each television 114 is coupled with an associated set top box 108, although multiple televisions 114 may be coupled to each set top box 108. Typically, the number of televisions 114 serviced at a customer premises is the same as a number of desired media streams for which the customer is subscribed. In the case of a digital video distribution system, the media streams comprise video feeds.
The media source transmits a plurality of source media streams via source virtual circuits (VCs) 118 to the multicast capable BLC 102. The multicast capable BLC 102, which typically combines the functionality of a Digital Loop Carrier (DLC), a Digital Subscriber Line Access Multiplexer (DSLAM), and a media gateway, transmits requested media streams to the DSL modem 106 via media VCs 116 in the POTS/DSL loop 104. Each DSL loop 104 may be provisioned with one or more media VCs 116. It is through the DSL modems 106 that the set top box, or boxes, 108 request the media streams. Thus, the multicast capable BLC 102 performs the multicast by connecting source media streams 118 to the media VCs 116 that are connected to the DSL modem 106.
Referring to FIG. 2, an alternate digital video distribution system to that shown in FIG. 1 is illustrated generally by numeral 200. The digital video distribution system 200 is similar that illustrated in FIG. 1, with the exception of an integrated set top box 202. The integrated set top box 202 performs the function of the DSL modem 106 and the set top box 108 of the system described in FIG. 1. Accordingly, the digital video distribution system 200 does not require the LAN 110.
Referring to both FIG. 1 and FIG. 2, digital video can be delivered to customers using DSL lines. Typically, customers are provisioned with multiple ATM VCs to carry the video stream. One VC is provisioned per video stream subscribed to by the customer, while additional VCs may be necessary for video stream control and other administrative use. Alternately, one VC is provisioned that comprises multiple video streams subscribed to by the customer.
An Internet Group Management Protocol (IGMP) is an Internet protocol that provides a way for Internet-connected devices to report their multicast group membership to adjacent routers. IGMP is often used to request specific video streams from the network. In order to achieve this, the set top box 108 reports group membership, where the group is a specific video stream. The IGMP protocol is designed to allow servers to be unaware of the exact number of clients that are members of a group. It is also designed such that group members do not report their own membership if they detect a peer in the same group. The result of these design characteristics is that if more than one set top box 108 is receiving the same video channel, not all of the available media VCs 116 are used. In contrast, when all set top boxes are receiving different video channels, all available media VCs 116 are used. The IGMP reduces bandwidth over the POTS/DSL loop 104 when possible, which is useful for reducing traffic on the network.
However, potential problems in the delivery of the video streams, and other multicast streams, can arise in both of the above described examples, depending on the disconnection mechanism used by the multicast BLC 102. Once a specific video stream is no longer desired, there are three primary methods for disconnecting the source video stream from the media VC 116 that is carrying it between the multicast capable BLC 102 and the DSL modem 106.
A first disconnecting method is referred to a normal, or slow, leave, and is described by IGMPv2, which is described in RFC 2236. Using this method, video streams do not immediately disconnect from their associated media VCs 116 when the set top box 108 sends an IGMP Leave message. Rather, in IGMPv2 and IGMPv3 (described in RFC 3376), the video streams only disconnect after a predefined time has elapsed. Functionally, the time is maintained by timers, which are initiated by the reception of the IGMP Leave message.
A second disconnecting method is referred to as a fast leave. In a fast leave, the video stream is disconnected from its associated media VC 116 as soon as the IGMP Leave message is received. The disconnection can be achieved in a proprietary manner or by setting the timers associated with reception of the normal IGMP Leave message to very short intervals, such as zero for example, with no retries.
A third disconnecting method is a time-out based on the lack of appearances of Membership Reports for a particular group. A time-out interval is based on the number of times a General Query has been sent on the interface used by the video stream. For IGMPv1, described in RFC 1112, no leave message is defined, thus this is the only available method of disconnection.
If the multicast capable BLC 102 is set to perform a fast leave on a single media VC 118 that is in use by multiple televisions 114, some subscribers may see a glitch in the video stream reception if one of the set top boxes 108 requests a leave. The glitch will likely occur because the multicast capable BLC 102 stops delivering the video stream immediately. Service is not restored for the original video stream until at least one of the set top boxes 108 that did not change video streams reports its membership.
If the multicast capable BLC 102 is set to perform a normal leave behaviour and all media VCs 116 are in use, a video stream change request may go unanswered due to the lack of availability of media VCs 116. For example, a typical user changes channels. This is realised by the set top box sending an IGMP Leave message followed by an IGMP Report message for the new video stream. However, due to normal IGMP Leave behaviour, the group just left has not been disconnected from the media VC. Since all other media VCs are in use, the Report for the new group is dropped.
Alternately, for the case where bandwidth is the resource, as opposed to a VC, the Report is answered, but excess bandwidth may be pushed down the line, degrading performance for all services until the group just left is disconnected.
Currently, there are several proposals to the above-described problems. In a first proposal, the number of VCs that are provisioned is one more than the number of set top boxes 108, and a normal leave is used. However, this method increases the administrative requirements and requires the permanent use of a media VC for transient conditions. For the bandwidth-as-a-resource scenario, this solution has the same result as provisioning extra bandwidth for all customers. That is, N+1 times the bandwidth is needed for N TVs 114.
A second proposal keeps track of individual members in a group. However, this proposal is not scalable. Further, this proposal does not solve the problem if some members do not report their membership in a group because they detect peers already in the same group.
Accordingly, it is an object of the present invention to obviate or mitigate at least some of the above-mentioned disadvantages.